Use for instead of next in contextlib.contextmanager#141275
Use for instead of next in contextlib.contextmanager#141275brandtbucher wants to merge 2 commits into
for instead of next in contextlib.contextmanager#141275Conversation
brandtbucher
added
performance
|
For tracking purposes, could you create an issue for that please? I also think it's worth a NEWS entry for people who are interested in this kind of optimization and understanding it. |
What if it is not? |
|
Sure, I can create an issue/NEWS.
The docs for
Besides, this still works (just as it does today) if another type of iterator happens to be returned, since they're required by the iteration protocol to define an
|
|
This PR is stale because it has been open for 30 days with no activity. |
|
@brandtbucher want to create an issue, so we can merge this? |
5 participants
This is a fun little optimization. According to some local microbenchmarks (basically entering and exiting context managers a million times), turning these
nextcalls intoforloops saves about 25% of the overhead this class introduces (~5% due to__enter__and ~20% due to__exit__). This is because:forloops for generators, so instead of calling through the C code fornextand re-entering the interpreter, we can "inline" the frame push instead. (This is also more JIT-friendly.)StopIterationexceptions here, just whether or not they were raised. Raising exceptions is expensive, and the interpreter has an optimization to avoid actually raisingStopIterationin normalforloops. (This is especially helpful in__exit__, where we advance the generator, expect aStopIterationto be raised, and then just throw it away!)This change isn't worth it for the
asyncvariant of this function, since neither of the above optimizations apply toasync forloops.